What this is. The resources/subscribe handler installed by trackResourceSubscriptions() (packages/server/src/server/mcp.ts:590-598) does an unconditional this._resourceSubscriptions.add(request.params.uri). The URI is entirely client-controlled input: nothing bounds the set size, nothing bounds the URI length, and nothing requires the URI to correspond to a registered resource (the handler accepts any string). On a sessionful posture (stdio, sessionful Streamable HTTP) the set lives for the lifetime of the connection, so an untrusted or buggy 2025-era client can send an unbounded stream of resources/subscribe requests with unique, arbitrarily long URIs and grow server memory without limit for as long as the session stays open.

Why nothing else prevents it. assertRequestHandlerCapability has no case for resources/subscribe, and the only mitigation the API offers is the optional onSubscribe veto hook — which every consumer this PR ships leaves unset: examples/resources/server.ts, examples/todos-server/todos.ts, the rewritten recipe in docs/servers/resources.md, and the JSDoc example all call trackResourceSubscriptions() bare (the JSDoc example does show a hook, but for URI-prefix filtering, not a count bound). So the default configuration — the one the docs teach — has no guard at all.

The in-package precedent. The SDK's own 2026-era analog treats exactly this class of client-driven bookkeeping as something that must be bounded: packages/server/src/server/listenRouter.ts:36 defines DEFAULT_MAX_SUBSCRIPTIONS = 1024, both createListenRouter (line ~124) and StdioListenRouter (line ~323) refuse further listens past the cap with a -32603 "Subscription limit reached" error, and both serveStdio and createMcpHandler expose this as a maxSubscriptions option defaulting to 1024. Now that the SDK owns the 2025-era bookkeeping too, the same protection belongs here.

Concrete walk-through. 1) A server calls server.trackResourceSubscriptions() (no options) and serves a sessionful stdio or Streamable HTTP connection. 2) A client sends resources/subscribe with params.uri = 'x://' + 'a'.repeat(1_000_000) + i in a loop, incrementing i. 3) Each request passes straight through the handler (no capability gate for the verb, no registered-resource check, no hook), executes _resourceSubscriptions.add(uri), and returns {}. 4) After N requests the Set holds N megabyte-scale strings; nothing evicts them until the connection closes. The equivalent loop against a 2026-era subscriptions/listen connection is refused after 1024 entries by the listen router.

Addressing the counter-argument. One reviewer position is that this merely restates the author's own open question ("Also open to adding a cap on the set... if reviewers want symmetry") and that the pre-PR hand-rolled Sets in the docs and examples had the identical exposure, so nothing regresses. Both points are true — which is exactly why this is filed as a nit rather than a blocker. But the question was explicitly left for reviewers to answer, and moving the bookkeeping from app code into the SDK changes who is responsible for the bound: an app hand-rolling a Set can be expected to own its own limits, while an SDK-owned default should be safe out of the box, the way the listen router already is. So the answer to the open question: yes, add a default cap.

How to fix. Either (a) accept a maxSubscriptions option on trackResourceSubscriptions defaulting to 1024 (matching the listen router's constant and error behavior — refuse with a ProtocolError once _resourceSubscriptions.size >= max), or (b) at minimum, extend the JSDoc/docs recipe to show an onSubscribe hook that enforces a count bound, so the documented default posture isn't unbounded. Option (a) is preferable for symmetry and because it protects the callers who never read that paragraph. This is not a merge blocker: no correct client hits it, and it is not a regression relative to the pattern the PR replaces.

What the mismatch is. The PR description's "Additional context" section states: "One design question deliberately left open for review: whether declaring resources: { subscribe: true } should enable tracking automatically instead of requiring the explicit call. This PR ships the explicit form — zero behavior change for existing servers", and the Breaking Changes section says "None — the API is opt-in; without it, behavior is byte-for-byte today's." The code in the diff does the opposite: McpServer.connect() (packages/server/src/server/mcp.ts:149-157) unconditionally calls _autoTrackResourceSubscriptions(), and that helper (~lines 645-655) installs the resources/subscribe and resources/unsubscribe handlers for any server whose declared capabilities include resources.subscribe — no explicit trackResourceSubscriptions() call required.

Concrete walk-through. 1) An existing app constructs new McpServer({...}, { capabilities: { resources: { subscribe: true } } }) and registers no subscribe handlers (a common posture today — the capability was declared, the verbs answered -32601). 2) On this branch, connect() runs _autoTrackResourceSubscriptions(); the capability check passes, neither verb has a handler, so _installResourceSubscriptionHandlers() runs. 3) A client's resources/subscribe now returns {} and the URI is recorded in resourceSubscriptions, where before it returned -32601 Method not found. That is precisely the automatic form the description claims was not shipped, and precisely the "behavior change for existing servers" it claims doesn't exist. The new test 'a declared resources.subscribe capability auto-installs tracking at connect' pins this behavior explicitly.

The rest of the PR agrees with the code, not the description. The changeset (.changeset/track-resource-subscriptions.md) says "Declaring the resources.subscribe capability now activates it automatically at connect()" and carries an explicit "Behavior change:" paragraph (previously -32601, now working SDK-owned handlers). The migration guide (docs/migration/upgrade-to-v2.md) adds a matching bullet, and docs/servers/resources.md is rewritten around "Declaring resources: { subscribe: true } is the whole opt-in." So the shipped artifacts — code, changeset, migration guide, docs, tests — are all internally consistent; only the PR description contradicts them. (The "Ten new tests" count is also stale; the test file has 13.) The description evidently predates the commit that graduated the feature from explicit to automatic and was never refreshed.

Why it matters. The description misleads reviewers on exactly the design question it flags as "deliberately left open for review": a reviewer reading only the description would believe the automatic-activation decision is still pending and that existing capability-declaring servers are unaffected, when in fact both have been decided in the code. It also means the "Breaking change" checkbox / "non-breaking" framing doesn't match the documented -32601 → {} behavior change for existing servers, which is worth a deliberate maintainer sign-off (including whether a "minor" changeset is the right vehicle for it).

How to fix. Update the PR description: state that the automatic form ships (declaring the capability alone activates tracking at connect(), hand-registered handlers still win), revise the Breaking Changes / Types-of-changes sections to acknowledge the documented behavior change for servers that declared resources.subscribe without handlers, and refresh the test count. Alternatively, if the maintainers prefer the explicit-only design the description describes, drop the _autoTrackResourceSubscriptions() call from connect() — but then the changeset, migration guide, docs, and tests all need reverting to match. Nothing in the merged code is wrong or self-inconsistent, so this is not a merge blocker — it's stale review metadata that should be corrected so the design decision is reviewed as what it actually is.